The present invention relates to Database Management Systems (DBMS), and more specifically, to managing data conversion for user-defined data types within a DBMS. Current DBMSs do not offer any functionality that allows for marshaling and unmarshaling of custom data types, nor do they allow comparison of these custom data types. User defined types (UDTs) are supported by many DBMSs, but they are either structured data types or distinct objects made up of built-in data types that are already supported by the DBMS.
Custom data types (CDTs) are defined as a data type that cannot be expressed as a series of built-in data types already supported by the DBMS. One example of a CDT is a bit string, where each bit represents a pre-determined value. CDTs are handled in applications and are typically stored in a database as a so-called Large Object (LOB) or, as in the previous example of a bit string, as a binary data type. There is no meaning associated with the LOB or binary data type. The meaning is handled at the application layer.
It can be difficult to manage the sharing of information and data conversion code for CDTs across an enterprise. CDTs require custom code (i.e., a type converter) to read and write the data from a DBMS to the calling application. As a consequence, it may be necessary to have type converters for the same data type in multiple programming languages as well as support various versions of the type converter code.
A known solution for custom data types in the Java™ programming language is that the Java Database Connectivity (JDBC) protocol allows for the storage of Java Objects directly into the DBMS through Java serialization. However, this solution is not language independent and other programming languages therefore need to know how to read and instantiate the Java object. It also requires the Java class definition to be available in the class path of each calling application.
The Structured Query Language (SQL) provides support for UDTs that are constructs made up of existing SQL Types. However, this solution does not provide the flexibility for a completely unique data type that is not based on any SQL Types. Similar solutions exist for other languages, such as the .NET language, that is, the solution is made up of database built-ins and applies only to the .NET language. The UDT must exist in the application itself and cannot be loaded dynamically from the DBMS.